2,000 Greater & Lesser Mysteries/2,000 Greater and Lesser Mysteries.iso/computer/virus/mys00475.txt

Text File | 1994-06-10 | 18.2 KB | 298 lines

Portal-Rmail-To: [e-mail]
Received: by portal.com (3.2/Portal 8)
    id AA13156; Wed, 26 Apr 89 01:38:23 PDT
Received: from Sun.COM (arpa-dev) by sun.Sun.COM (4.0/SMI-4.0)
    id AA18522; Tue, 25 Apr 89 23:07:59 PDT
Received: from sun by Sun.COM (4.1/SMI-4.0)
    id AB12617; Tue, 25 Apr 89 23:07:12 PDT
Message-Id: <[e-mail]>
Received: from LEHIIBM1.BITNET by IBM1.CC.Lehigh.Edu (IBM VM SMTP R1.2) with BSMTP id 5945; Wed, 26 Apr 89 02:02:46 EDT
Received: by LEHIIBM1 (Mailer R2.03A) id 5720; Wed, 26 Apr 89 02:02:42 EDT
Date:         Wed, 26 Apr 89 02:02:41 EDT
From: Revised List Processor (1.5o) <[e-mail]>
Subject:      File: "V101 2" being sent to you
To: "Gary F. Tom" <sun!portal!cup.portal.com!garyt>

Subject: Virus 101 - Chapter 2
From: [e-mail] (George Woodside)
Newsgroups: comp.sys.atari.st,comp.sys.apple,comp.sys.mac,comp.sys.ibm.pc
Date: 6 Mar 89 14:00:21 GMT
Reply-To: [e-mail] (George Woodside)
Organization: Citicorp/TTI, Santa Monica

In response to a lot of the mail I've received:

1) You haven't missed the "rest of the chapters". I'm posting them as I
   get them written.

2) You may not agree with me. I tried to set down the definitions and
   terms as I would be using them, for the benefit of those who weren't
   familiar with them. This whole area is rather vague, and most of us
   in the trenches and making up the rules, as we learn the game.

When we left our virus at the end of Chapter 1, it had managed to get itself
installed in our system by being present on the boot sector of a disk in the
machine at cold start or reset.

Another way a virus may be installed is via a trojan horse program. Trojan
horses come in many flavors. Some disguise themselves as programs which
provide some useful function or service, while secretly doing something
else. The something else may be installing a virus, sabotaging some part of
a disk, setting up hooks to steal passwords on time sharing systems, or
whatever else you can imagine. In the event of the virus installer, the
trojan horse has a bit more flexibility than a typical boot sector virus,
simply because it doesn't have to fit itself into a relatively small space.
Since it is hiding in a larger program, it can be whatever size is necessary
to accomplish the task.

A typical boot sector contains information about the layout of the disk it
resides upon. This block of data requires 26 bytes. The first three bytes of
the boot sector are left available for an assembly language "jump" command,
to allow the execution of the code to skip over the boot sector's data
block. And, the boot sector must add up to the proper magic number to have
executable status. That will require another two bytes, since the checksum
is a 16 bit value. So, 31 bytes are allocated. Since (at least in the 68000
family) machine instructions are always 16 bits and must begin on an even
address, 32 of the 512 bytes in the boot sector are not available to any
executable program. So, there are 480 bytes available for the executable
code. Machine instructions vary in length, depending upon what they do, and
how much additional information is required. In the 68000, instruction
lengths vary from one to five words, but a reasonable average instruction
length for a program is just over two words. That translates the 480 bytes
to 120 instructions.

The virus must contain the code to install itself, reserve the memory it
occupies to keep subsequent programs from over-writing it, spread itself to
other disks, and whatever it really intends to do once it decides it is time
to act. That's quite a bit of code to fit into 120 instructions, unless it
extends itself by loading some other part of the disk, or a file.

Files are pretty much out of the question. Most computer users would notice
if some file they didn't recognize started popping up on a lot of their
disks. There are attributes settable in a disk directory which can be used
to tell the operating system that certain files are "Hidden" or "System"
files. If the file had the proper status bits set, it could prevent itself
from appearing in normal disk directory displays. There are, however, more
flexible disk directory listing programs which will display the entries for
these files, as well as normal files. There is also the problem of the space
the hidden file occupies, as well as the directory entry. The space
available on the disk will be less than it should be, since the hidden file
is present. These symptoms would not escape detection for long.

A more effective method is the use of specific disk sectors. The standard
disk layout covered in the preceeding chapter mentioned such things as File
Allocation Tables, and disk directory space. In a standard format Atari
disk, for example, each FAT is 5 sectors long, and the directory is 7
sectors long. That is more than enough FAT space to accomodate the entire
disk. A virus in need of more space than 480 bytes might write the remainder
of itself in the last sector of the FAT (I have one that does this). It
might also write itself in the last sector of the directory, taking
advantage of a quirk in the operating system.

When a disk is formatted, all data sectors are normally filled with a
pre-defined value, E5 (hexadecimal). The directory and FAT space is usually
set to 00. When a directory entry is made active, the file name is written
in the directory, along with some other required information. When a file is
deleted, the first byte of the directory entry is set to E5. That makes the
entry available again. This is a carry over from the early days of floppy
disks, when where the directory would exist on a disk was not as well
defined. The directory entries had to appear as empty on a freshly formatted
disk, so E5 was used as a deleted entry mark. That way, no matter where the
directory was, a freshly formatted disk would always appear as empty. Now,
since disk formats are more flexible, the directory is located by
parameters, and normally the entire directory space is zeroed at formatting
time. Since an active entry will have some legitimate ASCII character in the
beginning of the file name, and a deleted entry will have E5 in the first
byte, it is generally assumed that encountering a directory entry with a
value of 00 in the first byte indicates that the entry has never been used.
Since directory entries are used (and deleted ones re-used) on a first-found
basis, finding one with 00 means that not only has it not been used, but
none of the ones following it will have been used either. Consequently, most
software stops looking at the directory entries when a 00 entry pops up. If
there are several more sectors available, there may be something hiding out
there, beyond the last used entry. While this method of hiding is not
foolproof, the typical virus is not concerned about being bulletproof in all
cases. It just has to survive long enough to reproduce itself, and it has
half the battle won. As long as it keeps spreading, sooner or later it will
survive long enough to do the task it is designed to do, then it wins both
halves of the battle.

There are other ways for the virus to get additional disk space. Typically,
floppy disks are not used up a sector at a time, but rather in groups of
sectors. Each group of sectors is referred to as a data "cluster". The
number of sectors in a cluster is variable, and is one of the parameters
stored in the boot sector. If the number of data sectors on the entire disk,
minus the boot sector, FATs, and directory, is not an exact multiple of the
number of sectors in a data cluster, the remaining sectors will never be
used by the opearting system. A clever virus can find them and hide there.
The inconvenience of this is that the unused sectors would normally be at
the end of the last track of the disk, causing long (and noticeable) disk
seeks to load or spread the virus.

There is a parameter in the boot sector designed to permit the disk to have
sectors reserved for any purpose, and not accessed as part of the normal
data area. A virus could also use this method to extend itself, but it, too,
has shortcomings. Using this feature requires the parameter to be set when
the disk has absolutely no data on it. Reserving sectors causes the start of
the data area to be moved further into the disk. While the data area would
be moved, the data already on the disk would not. Consequently, altering the
reserved sectors parameter would make all files on the disk garbage. (They
could be returned to proper status by restoring the original value to the
reserved sectors parameter, providing no disk write had occurred.) There
would also be the problem of the disk's free space being less that it
should.

Consequently, if a virus needs extra space, using prescribed system features
or hidden files is not a good choice, since it is too easily detected. The
approach used so far is to hide in sectors unlikely to be used, and hope to
spread before they get clobbered (and it works).

OK, so now the virus has managed to get onto a disk in your library, and
then get itself booted into your system at startup or reset. It may have
been on a disk you received from someone, and booted with, or it may even
have been installed by a trojan horse, but it is in your system. How does it
spread?

There are ways, and then there ways.....

The most common method is through the vector reserved for floppy disk read
and write functions. As we saw in Chapter 1, floppy disks get changed (some
surprise, eh?). One disk is removed, and another is inserted. When that
happens, the operating system is notified by the physical act of changing
the disk that the event has occurred. How that event is detected will vary
with different disk drives, but there are two common methods. One is the
disk drive latch. Some hardware reports the transition of the latch on the
floppy disk drive's door. When the locking lever is moved, a signal is sent
to the disk controller card, indicating that the disk door has been opened.
(Door is a carry over term from older drive mechanisms which had fully
closing doors over the disk drive slot.) The operating system makes note of
the fact that a disk change may have occurred.

The other method is the write protect notch. On both 5 1/4 and 3 1/2 inch
disks, the write protect notch tab is located in a position which makes it
impossible to fully remove and install a disk without having the write
protect detection mechanism be fully obstructed at some point, and fully
unobstructed at some point. The detection mechanism may be a physical sense
switch, or an optical sensor. Either way, as the body of the disk is removed
from the drive, it will be blocked. Then, when the disk is out, the sense
area is open. So, the drive will report transitions on the status line. The
operating system notes the change, and sets the necessary flags to indicate
that the disk may not be the same one that was there a little while ago. It
may also be, if the same disk was re-inserted, but that's not important. The
fact that it may have changed is very important. Attempting to read or write
to the disk, without first noting the characteristics of it, could be very
destructive.

When the next access of the (possibly) changed disk occurs, the operating
system will read the boot sector. In MS-DOS systems, I believe that the
operating system assumes that if there is a possiblity that the disk has
changed, it assumes that it has, dumps all information relative to the old
disk, and starts fresh. In the Atari, the operating attempts to be a bit
smarter. The boot sector contains a serial number which is supposed to be
unique across all disks. This serial number is 12 bits long, and is assigned
when the disk is formatted. If there is a possibility that the disk has
changed, the operating system reads the serial number. If the serial number
is different than before, the disk has changed, all old data is wiped out,
and the new serial number is noted. If the serial number is the same, the
disk has presumably not changed, and the data in the operating system's
internal buffers is assumed to be valid. This leads to thoroughly trashed
disks if two disks have identical serial numbers, and are used
consecutively.

In any event, when a possible disk change has occurred, the boot sector is
always read to determine the characteristics of the new disk. The operating
system uses the floppy disk read function to access the first sector on the
disk. As previously noted, this disk read function is pointed to by a
vector. If the vector has been altered to point to a virus, the plot
thickens...

We will assume a typical floppy disk boot sector virus for a while, and see
exactly what happens. The virus first checks the number of the drive being
accessed. If it is not a floppy disk, it passes the call on to the address
it found in the vector. No harm done.

If the call is to a floppy disk, most viruses check the side, track, and
sector of the call to see if it is the boot sector. If it isn't, it passes
the call on, and again, no harm done. Why? Performance. Not that the virus
cares about good disk performance, mind you. What it cares about is being
noticed. If it was busy snagging all the disk calls, and checking the boot
sector all the time, there would be an incredible increase in disk head
seeking, and a very noticeable drop in performance of the system. Anyone
with at least half a brain (witch inkluds sum smarter komputer pepel) would
notice that, and would become inquisitive about what was happenning. The
virus would have given itself away. No self-respecting virus would want to
be detected before it got a chance to spread, and possibly wreak a bit of
havoc, so it remains inactive until it can accomplish its task unnoticed.

When the read call is to the boot sector, the virus goes into action. The
data is read into a buffer, as designated by the host operating system's
call, exactly as expected. Normally, the disk read function would return to
the operating system at this point, but the virus doesn't. Depending upon
the sophistication of the virus, several things may happen. Some viruses
will first check the image of the boot sector in the buffer, to see if they
are already on the disk. If they find the disk already has the virus, the
go back to sleep (pleased, we assume!). Some even check revision levels in
the virus image, and replace themselves if the disk had a more recent
version of themselves!

If the image from the boot sector is not the virus, some will check to see
if the image was of an executable boot. If it was, the virus does not alter
it. Doing so would make a self-booting disk fail forever after, and would
probably lead to the detection of the virus. Other viruses, not as
sophisticated, will not execute this test, and may be spotted more readily.

Now, assuming that the boot sector is not executable, or that it is but this
virus is too dumb to leave it alone, it's time for the virus to spread.
There is a copy of the boot sector from the original virus disk in a
reserved memory area, from the original boot up process. The executing copy
of the virus knows where that is, since it reserved the memory for itself
and the image at the same time. The characteristics of the disk the virus
came from may not be the same as the disk in the machine now.  Depending
upon the operating system's standards, the virus will either copy the disk
parameter information from the current disk into its own image buffer, or
copy its image into the current disk's buffer, leaving the disk's parameters
unchanged. Either way, the result is a copy of the current disk's
parameters, combined with the executable image of the virus.  Now, the
executable status checksum must be computed, and added to the buffer. This
may be accomplished by a routine in the virus, or by an operating system
call. If the virus is on an Atari, it might be careful enough to insure that
the serial number on the new disk remains the same.  Failing to do so would
lead to all disks with the virus having the same serial number. That would
lead to disks being accidently altered (due to the serial number test), and
the virus would probably be detected too soon.

When the new checksum is completed, the updated boot sector is re-written to
the disk. All this occurs in much less than the time required for the floppy
disk to make a single revolution, so the boot sector is re-written on the
next spin. Since the rotation speed of the disk is either 300 or 360 rpms,
the total time lost is less than 1/5 of one second. Nearly impossible for
anyone to notice, when combined with the time required for the drive to load
the head, seek to track zero, read the sector, etc.

The only potential problem here is one of the virus' intended victim's
primary levels of defense: the write protect feature. Despite rumors to the
contrary, I have not seen a virus capable of writing to a write protected
disk. The hardware in the disk drive will not write if the write protect
status is set. It reports an error to the operating system. The virus can
not override this protection, but it must be wary of it. Older viruses were
sometimes spotted when a system error occurred, reporting that an attempt
was being made to write to a disk which was write protected. If the function
being performed (listing a directory, for example) should not be writing to
the disk, there was reason to become suspect. Most viruses now are more
sophisticated. They take over the error vector before attempting the write,
and restore it afterwards. That way, if the attempt to spread themselves to
the new disk fails, the error never gets reported. While the user doesn't
know that the attempt was ever made, the disk also doesn't get infected.

Many viruses run counters. Some count the number of already infected disks
they have seen, while others count the number of disks they infect. Either
way, the counting viruses have some threshold they are attempting to reach.
When they reach that number, they (presumably) consider themselves
thoroughly spread, and it is now time to start their third act.

End of Chapter 2.
--

*George R. Woodside - Citicorp/TTI - Santa Monica, CA
*Path:       ..!{philabs|csun|psivax}!ttidca!woodside